Synchronisation in communication systems

ABSTRACT

A method and a communication bus are provided having nodes. Each of the nodes includes a transmitting element to transmit data to another node on the bus, and a receiving element to receive information from another node on the bus. A communication channel is between the transmitting and receiving elements within each node, a transmitter state machine logic controls the synchronisation of the transmitting element, and a receiving state machine logic to control the synchronisation of the receiving element. A storage area maintains the status of synchronisation of the bus. Communication data is synchronised via a bus connecting first and second nodes. A plurality of encoded bytes, each encoded byte represented as a 10 bit code, is transmitted from the first node. The second node receives and decodes the bytes, where any decoding errors in a byte are detected. A synchronised status is indicated.

REFERENCE TO RELATED APPLICATIONS

This application is a divisional application of U.S. patent applicationSer. No. 10/378,653 filed on Mar. 5, 2003, which claims priority toBritish Patent Application Serial No. 0205142.3 filed Mar. 5, 2002 inGreat Britain. The subject matter of the earlier filed applications ishereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is concerned with synchronisation of basebandcommunications in a wireless communications network.

2. Description of the Related Art

Within a base transceiver station of a wireless communications network,a bus protocol is used to communicate between different nodes. Thepresent invention is concerned particularly but not exclusively withcommunication between baseband (BB) and radio frequency (RF) nodes inthe base transceiver station. Nodes are implemented in a plurality ofdifferent ways, and in the following description it is understood thatthe term “node” implies any appropriate hardware unit, for example anASIC, processor or FPGA, etc.

The bus protocol used between the different nodes of the basetransceiver station is used to transfer digitised transmitter (TX) andreceiver (RX) samples as well as other information.

The present invention addresses the problem of synchronising a bus, inparticular a high speed bus operating a bus protocol used forcommunication between different nodes in a base transceiver station.

It is a further aim of the present invention is to provide a frameformat used in conjunction with synchronisation methods forsynchronising communications on a multi-mode communications bus, whichdoes not require complex circuitry.

SUMMARY OF THE INVENTION

In general terms, the invention relates to bus synchronisation usingidle codes, with the possibility of detecting 8bl10b decoding status. Inthe described embodiment initial synchronisation and synchronisation atrun time is discussed. The position in a frame and value of the idlecode is utilised.

According to one aspect of the present invention Is a provided a methodof transmitting data at a line rate from a wireless interface to a busoperating at a bus rate, the method comprising transmitting the data ina packet format consisting of a plurality of frames each having aplurality of time slots, each time slot having successive messagegroups, wherein each message group comprises a plurality of datamessages containing said data and an idle code containing no said data;wherein the number of idle codes in each frame is selected so that thebus rate matches the line rate.

According to a further aspect of the present invention there is provideda method of transmitting data at a line rate from a wireless interfaceto a bus operating at a bus rate, the method comprising transmitting thedata in a packet format consisting of a plurality of frames each havinga plurality of time slots, each time slot having successive messagegroups, wherein each message group comprises a plurality of datamessages containing said data and an idle code containing no said data;wherein the number of idle codes in each frame is selected so that thebus rate matches the line rate.

According to yet another aspect of the present invention there isprovided a communication bus operable at a bus rate and having at leasta first node and a second node that are linked by communication channelsfor transmitting at said bus rate data generated at a line rate, saidfirst node having a transmitting element and said second node having areceiving element, wherein the transmitting element of said first nodeis operable to transmit data in a packet format consisting of aplurality of frames each having a plurality of time slots, each timeslot having successive message groups, wherein each message groupcomprises a plurality of data messages containing said data and an idlecode containing no said data; wherein said number of idle codes in eachframe is selected so that the bus rate matches the line rate and whereinthe receiving element of the second node is arranged to detect said idlecodes for synchronisation purposes.

According to a still further aspect there is provided a method ofsynchronising a data communication over a bus in a packet format, saiddata having been generated at a line rate over a wireless interfaceconsisting of a plurality of frames each having a plurality of timeslots, each time slot having successive message groups, wherein eachmessage group comprises a predetermined number of data messagescontaining said data and an idle code containing no said data, themethod comprising detecting at a bus node said idle codes until apredetermined number of said idle codes have been detected indicatingsuccessful synchronisation.

According to a still further aspect there is provided a method ofsynchronising data communication via a bus connecting first and secondnodes comprising: transmitting from the first node a plurality of bytes,each byte representing a 10 bit sequence as an 8 bit code; receiving anddecoding said bytes at the second node, whereby any 8b10b encodingerrors in a byte are detected; and indicating a synchronised status forthe bus based on the detection of received bytes which do not contain8b10b decoding errors.

According to a still further aspect there is provided a method ofsynchronising data communication via a bus connecting first and secondnodes comprising: transmitting from the first node a plurality of bytes,each byte representing a 10 bit sequence as an 8 bit code; receiving anddecoding said bytes at the second node, whereby any 8b10b encodingerrors in a byte are detected; and indicating an unsynchronised statusfor the bus based on the detection of received bytes containing 8b10bdecoding errors.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention and to show how thesame may be carried into effect, reference will now be made by way ofexample to the accompanying drawings in which:

FIG. 1 shows the basic structure of a wireless communications network;

FIG. 2 shows the context of the present invention for use at basebandfrequencies;

FIG. 3 shows an embodiment of the architecture of the physical basebandbus of the present invention;

FIG. 4 shows the baseband bus protocol stack according to an embodimentof the present invention;

FIG. 5 shows a frame format according to an embodiment of the presentinvention;

FIG. 6 shows an embodiment of the message structure of the presentinvention;

FIG. 7 shows two communicating nodes of the baseband bus;

FIG. 8 shows a state transition diagram of the logic implemented withinthe receiving elements of each baseband node;

FIG. 9 shows a state transition diagram of the logic implemented withinthe transmitting elements of each baseband node; and

FIGS. 10 a and 10 b show the bit patterns for the idle codes accordingto an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 shows the traditional elements of a wireless communicationsnetwork. A Mobile Switching Center (MSC) 2 acts as an interface withother networks, for example the Public Switched Telephone Network(PSTN). The MSC 2 controls a plurality of Base Station Controller's(BSC) 4, where each BSC 4 in turn controls plurality of Base TransceiverStations (BTS) 6. Each BTS 6 has a certain coverage area known as a“cell”, which is used to communicate with mobile stations in theirrespective coverage areas.

FIG. 2 shows the typical components of a transceiver used in wirelessnetworks where radio signals are transmitted and received using antennae10. These radio signals are transferred at a carrier frequencydetermined by a carrier generator 14. Spectrum allocations are licensedand will vary depending on the country involved and the type of airinterface being used, for example WCDMA, GSM, etc. In a typicaltransceiver, for example as would be found at each of the BTS's 6 ofFIG. 1, there is a baseband circuitry 16 concerned with the processingof baseband signals. These baseband signals are then converted into acarrier signal by RF circuitry 12 for transmission by the antennae 10.The embodiments of the present invention discussed herein are in thecontext of the baseband circuitry 16, where a bus protocol connects BBand RF nodes together.

FIG. 3 shows the physical architecture of the baseband bus where nodes20, 22, 24, 26 are chained in a point-to-point manner according to afirst embodiment of the present invention. Each of the nodes can beimplemented by using an Application Specific Integrated Circuit (ASIC).The nodes communicate using a first set of communication channels 28 inan Uplink direction and over a second set of communication channels inthe opposite or Downlink direction 30. Each of the nodes are shown ashaving a plurality of communication channels referred to herein aslinks, i.e. 1 to k, in either direction. Some of the nodes may have anRF interface. Other nodes are baseband nodes with no RF interface.

Packetised data may be sent over the baseband bus. As can be seen fromFIG. 3 the bus is implemented using a plurality of links. A single linkis however possible. In a preferred embodiment the baseband bus consistsof point-to-point connections forming a chained bus. In this embodiment,the point-to-point connections are achieved using Low VoltageDifferential Signalling (LVDS).

The baseband bus uses a three-layer protocol with fixed length messages.Any information to be sent over the baseband bus is packed into messagesof known type. The three layers are shown in FIG. 4. The physical layer60 is responsible for the transmission of messages and includes framing,coding and serialisation of the messages. The transport layer 62 isresponsible for the end-to-end delivery of the messages or routing ofthe messages. The application layer 64 provides the mapping of differenttypes of packets to the payload.

In CDMA applications, data at the application layer is continuous, butfor transfer over the bus, the continuous data of the application layeris time sliced into short messages that are transferred over thehigh-speed physical layer. At the receiving node a continuous stream isrecovered.

FIG. 5 shows a frame 70 of the physical layer with a certain packetformat being sent over the bus in both the uplink and downlinkdirections. The frame has a fixed 10 ms period. Frames are insertedconsecutively onto the bus. A frame is split into fifteen timeslots 72where each timeslot contains a plurality of message groups 74. Eachmessage group 74 has a fixed predetermined number of data messages 76,one control message 78 and an IDLE message 80.

A preferred embodiment of the message structure 76 is shown in FIG. 6.These messages are transmitted over the physical layer 60 shown in FIG.4. In this embodiment, the messages are of a fixed length of 19 byteshaving a header portion 90 of 3 bytes and a payload portion 92 of 16bytes. Thus, all messages including control and data have the samemessage definition. For one embodiment as will be described hereafter,the idle message is in the form of an idle byte.

When there is no data message to transmit, that is, no message has beenreceived from the transport layer for a given time slot, then thephysical layer 60 transmits an empty message, which can be implementedby transmitting “1” bits for the entire message. The physical layer atthe receiving node will detect the existence of an empty message andrejects such messages, thereby making these messages invisible to theupper protocol layers 62,64.

In the embodiment shown in FIG. 5, the message group 74 comprises onecontrol message 78 inserted after every twenty data messages 76 and anIDLE byte 80 inserted after the control message 78. The same IDLE byte80 is used at the end of each message group 74 with the exception that aspecial IDLE byte 82 Is used in the final timeslot to identify the endof the frame. The significance of the special IDLE byte 82 will bediscussed later.

In the present embodiment, the bus speed is chosen to be 768 Mbps. Aderivative of the BTS reference system clock is used as a clock for thebaseband bus and the physical layer 60 of the bus protocol issynchronised to the BTS system clock. However, application layers of thebus protocol can operate asynchronously with respect to the timing ofthe physical layer, which is especially useful for GSM or EDGEapplication where data is not continuous but instead is transmitted inbursts and is inherently asynchronous.

For the present embodiment, consider the situation of a WCDMA uplink.Consider a signal described in terms of its in-phase component (I) andits quadrature component (Q) where the I and Q values are each 8 bits.

At a sample rate of 7.68 Msps (Mega samples per second), this gives apayload rate of 7.68M*(8*2)=122.88 Mbps (Mega bits per second). Sincethe packet has a 3 byte header and 16 byte payload, the packet rate is122.88*(19/16)=145.92 Mbps. After an 8b10 coding scheme is used, theline rate is 145.92M*(10/8)=182.4 Mbps.

FIG. 3 shows a plurality, i.e. 1 to k links being used to communicate ineither direction. Each link supports four paths so that each uplink, ofthe group of uplinks 28, Is required to support four uplink paths,giving a line rate of 182.4M*4=729.6 Mbps per link. if control messagesare inserted every twentieth packet, this gives a line rate of729.6*(21/20)=766.08 Mbps.

However, a bus speed of 768 Mbps has been chosen. Therefore an extra768−766.08=1.92 Mbps is needed in order to match the line rate to thebus speed. 1-0 achieve this, taking into account the 8bl Ob coding,1.92M*(8/10)=1.536 Mbps of “plain” data needs to be inserted, which is1.536 Mbps/8=192000 “plain” bytes per second. Each frame has a timeperiod of 10 ms, therefore 192000/100=1920 IDLE bytes per frame areinserted. Each frame has 15 time slots resulting in 1920/15=128 IDLEbytes per time slot. There are 2560 data messages per time slot, whichmeans 128/2560=1 byte per 20 messages should be an IDLE byte in order tomatch the tine rate to the bus speed.

Therefore, by insertion of IDLE bytes it becomes possible to match theline rate to be an integer multiple of the system clock rate andalleviates the need for additional complex circuitry needed to accountfor a mismatch between the line rate and the bus speed.

FIG. 7 shows the LVDS point-to-point connections in an uplink direction30 and a downlink direction 28 between a first node 20 and a second node22 of the bus. Each LVDS point-to-point connection corresponds to eachof the 1 to k links shown in the uplink 28 or downlink directions 30 ofFIG. 3. Each node 20, 22 comprises a transmission element 40, 48 and areceiving element 44, 52. In the downlink case, a transmission element40 transmits information from a first node 20 to a receiving element 44in a second node 22 using LVDS connections. In the uplink direction, atransmitting element 48 transmits information from a second node 22 tothe receiving element 52 of a first node 20. A communication channel 41exists between the transmitter 40 and receiver 52 of the first node 20.Also, a communication channel 43 exists between receiver 44 andtransmitter 48 of the second node 22. These communication channels maybe used by receivers on a node to inform the transmitters if a loss ofsynchronisation occurs.

It can also been seen that each of the transmitting 40, 48 and receivingelements 44, 52 have their own respective state machine logic 42, 46,50, 54. FIG. 8 is a state transition diagram showing the state machinelogic 46, 54 of the receiving elements 44, 52. FIG. 9 Is a statetransition diagram showing the state machine logic 42, 50 of thetransmitting elements 40, 48. Tables 1, 2 and 3 given below can be usedto interpret these state transition diagrams.

Table 1 below provides a definition of the signals used in the statemachine for synchronisation.

TABLE 1 Signal Definition Active state NdFifo Valid Node clock domainFifo valid Active high = ‘1’, signal to indicate that the fifo default =‘0’ is passing valid bytes to the rx decoder FRAME_IDLE_VALID Frame IDLEbyte (K28.7) is Active high = ‘1’ for received to indicate that a asingle cycle when new frame boundary is a K28.7 IDLE byte present isreceived. Default = ‘0’ SET_RUN_TIME_MODE Value ‘1’ enables run timeActive high = ‘1’, mode, ‘0’ disables run time default = ‘0’ mode.Messages are transferred over the bus in run-time mode.ENABLE_BUS_TRANSCEVER The bus transceiver is Active high = ‘1’, enabledby value ‘1’. This default = ‘0’ enables the transmitter to startsending IDLE. RESTART_FROM_DISABLE This signal resets the state Singlecycle Active machine when the state is high pulse = ‘1’, either DISABLEOR default = ‘0’ FRAME_DISABLE.

It should be noted that the IDLE code 80 inserted at the end of eachmessage group 74 is referred to herein as the “K28.5” IDLE byte, whereasthe special IDLE code 82 inserted at the end of each frame 70 isreferred to herein “K28.7” IDLE byte. FIG. 10 a and FIG. 10 b show thebit patterns that make up the K28.5 and K28.7 idle bytes respectively,in the 8 bit domain. These bit patterns are known as so-called “commacharacters”, which are uniquely chosen to indicate possible errors.

These codes (and other data bytes) are transmitted as 10 bits using an8b10b encoding scheme, for example as described in “A DC-Balanced,Partitioned-Block, 8B/10B Transmission Code”, by Widmer and Franaszek,IBM J. Res. Develop. Vol. 27 No. 5, September 1983. The transmitter hasmeans for encoding the 8b bytes into 10b codes and the receiver hasmeans for decoding the codes and for error checking.

Table 2 below defines the state transitions and triggers required forthese transitions for the state machine logic 46, 54 of the receivingelements 44, 52.

TABLE 2 Transition Trigger Comment 1 ENABLE_BUS_TRANSCEIVER = ‘1’Message Group counter reset. (values changes from ‘0’ to ‘1’) 2 SYNC_Tvalid Message Groups SYNC_T message groups of valid received IDLE byteshave been received 3 DISABLE_T Message Groups or Timeout counter hasbeen ENABLE_BUS-TRANSCEIVER = ‘0’ reached without SYNC_T valid MessageGroups being received or Application layer eforces the state to DISABLE.4 Not (2 or 3) <SYNC_T valid Message Groups have been received andtimeout count has been reached 5 RESTART_FROM_DISABLE = ‘1’ Applicationlayer has acknowledged that the state machine is in the DISABLE stateand restarts the synchronization process 6 UN SYNC_T consecutive invalidSynchronization lost due to UN Message Groups received SYNC_Tconsecutive invalid Message Groups received 7 Not (6 or 8 or 10)Physical layer synchronization is maintained and valid IDLE bytes arebeing received. 8 ENABLE_BUS_TRANSCEIVER = ‘0’ The transceiver isDISABLED. This transition is forced by Application layer. 9RESTART_FROM_DISABLE = ‘0’ Wait in the DISABLE for the Application layerto generate a RESTART_FROM_DISABLE signal. 10 SET_RUN_TIME_MODE = ‘1’ &Run time mode has been FRAME_IDLE_VALID activated and a K28.7 frameboundary IDLE byte received to indicate the start of empty messages. 11Not (12 or 13) Stay in the Frame_UNSYNC_(—) state 12 FRAME_SYNC_Tconsecutive valid message groups are received 13 FRAME_DISABLE_T invalidmessage Transition to the groups are received or FRAME_DISABLE state asENABLE_BUS_TRANSCEIVER = ‘0’ FRAME_DISABLE_T invalid or SET-RUN-TIME =‘0’ message groups have been received or Application layer halts thetransceiver. 14 Not 15 Wait for a RESTART_FROM_DISABLE signal. 15RESTART_FROM_DISABLE = ‘1’ The static machine has been reset byApplication layer (i.e. restart the initialization process). 16 Not (17or 18) Valid Message Groups are being received. Normal message receptionstate. 17 FRAME_UNSYNC_T consecutive Whilst in the FRAME_UNSYNC invalidmessage groups are received. state, FRAME_UNSYNC_T consecutive invalidmessage groups are received. 18 ENABLE_BUS_TRANSCEIVER = 0 orTransceiver DISABLE SET_RUN_TIME = ‘0’ 20 GO_TO_FRAME_SYNC = 1 & Fortest purposes: Run time mode SET_RUN_TIME_MODE = 1 & has been activatedand a K28.7 FRAME_IDLE_VALID frame boundary IDLE byte received toindicate the start of the empty packet bytes. 19 SET_RUN_TIME_MODE = ‘1’& When in UNSYNCHRONIZED FRAME_IDLE_VALID state, run time mode has beenactivated and a K28.7 frame boundary IDLE byte received to indicate thestart of empty messages.

Table 3 below defines the state transitions and triggers required forthese transitions for the state machine logic 42, 50 of the transmittingelements 40, 48.

TABLE 3 Transition Trigger Comment 1 ENABLE_BUS_TRANSCEIVER = ‘1’ LOS inreceiver is initially “1” (values changes from ‘0’ to ‘1’) 2 LOS = ‘0’Receiver has acknowledged that SYNC_T IDLE bytes have been received.Receiver has acknowledged the transition to SYNCHRONISED state bychanging LOS to “0” 3 ENABLE_BUS_TRANSCEIVER = ‘0’ Transmitter has beenDISABLE. 4 ENABLE_BUS_TRANSCEIVER = ‘0’ Wait for Receiver to and LOS =‘1’ acknowledge receipt of SYNC_TIDLEs or transmitter DISABLE. 19 GO TOFRAME SYNC = ‘1’ Go to Frame UNSYNC state 5 RESTART FROM DISABLE = ‘1’Transmitter has been reset and can transition to UNSYNCHRONISED andstart sending IDLE. 6 LOS = ‘1’ Receiver has generated a Loss Of Signal.7 LOS = ‘0’ AND Send IDLE bytes (with K28.7 ENABLE SUS TRANSCEIVER = ‘1’at Frame boundary). and SET RUN-TIME MODE ‘0’ 8 ENABLE BUS TRANCEIVER =Transition to the DISABLE ‘0’ state. 9 RESTART FROM DISABLE = Stay inDisable state ‘0’ 10 SET RUN-TIME MODE = Transition to the ‘1’ and FClk= ‘1’ FRAME_UNSYNC when the transmitter has sent a K28.7 (last byte inthe frame. 11 LOS = ‘1’ AND (ENABLE BUS Stay in Frame_Unsync stateTRANCEIVER) = ‘1’ OR SET RUN-TIME MODE_‘1’) 12 LOS = ‘0’ Receiver hasacknowledged that it has received FrameUnsyncT valid Message Groups. 13ENABLE BUS TRANSCEIVER = ‘0’ Go to FrameDisa e state as the Transmitterhas been DISABLE. 14 RESTART FROM DISABLE = Stay in Disable state. ‘0’15 RESTART FROM DISABLE = Restart the transmitter go to ‘1’ theUNSYNCHRONISED state. 16 LOS = ‘0’ AND Stay in Frame_Sync state. ENABLEBUS TRANSCEIVER = ‘1’ AND SET TUN-TIME MODE = ‘1’ 17 LOS = ‘1’ Receiverhas de-asserted the Loss Of Signal input so the transmitter must sendempty messages. 18 ENABLE BUS TRANSCEIVER_(—) Disable Transmitter ‘0’ ORSET RUN-TIME MODE_(—) ‘0’

Broadly speaking, there are two synchronisation algorithms which areapplied, i.e. initial synchronisation and frame synchronisation. Initialsynchronisation allows an initial check on the link quality of the bus,whereas frame synchronisation allows continuous monitoring of the linkquality when the bus is in run time mode. The synchronisation algorithmscan report link status information of the bus to upper layers of theprotocol stack.

Initial synchronisation is performed when a bus node is booting up. Thepurpose of the initial synchronisation is to determine the status ofeach bus interface. That is, checking the status of a node'stransmitting and receiving elements. Synchronisation may be unsuccessfuldue to a missing neighbouring node or a failure of the link.

In the present embodiment, the sequence of steps for initialsynchronisation is the following:

-   -   Set state to UNSYNCHRONIZED.    -   Reset the message group counter to zero.    -   Start transmitting a constant stream of IDLE bytes from the        transmitting element of any node, e.g. 20.    -   Start reading the IDLE bytes at the receiving element of any        node, e.g. 22.    -   A message group is considered to be valid when all the IDLE        bytes are properly received and there are no 8b10b decoding        errors. Otherwise, a message group is considered to be invalid.        It should be appreciated that there are (21 messages*19 bytes        per message)+1 IDLE byte=400 bytes in a message group.

When in the state UNSYNCHRONIZED and a value of SYNC T consecutive validmessage groups have been received, the state of the state machine thenis set to the SYNCHRONISED state.

When in the state SYNCHRONIZED and a value of UNSYNC T consecutiveinvalid message groups have been received, the state of the statemachine then is set to the UNSYNCHRONISED state. Also, the message groupcounter is set to zero.

When in the state UNSYNCHRONIZED and a value of DISABLE T message groupshave been received, the state of the state machine then is set to theDISABLE state. The value of DISABLE T is larger or equal to the value ofUNSYNC T. When either of the transmitting or receiving elements of anode enter the DISABLE state, the application layer 64 is informed by aninterrupt which then can restart the synchronization procedure.

The above synchronization algorithm can be generalized by consideringvalidity of consecutive received bytes instead of message groups.Furthermore, synchronization can be based on any transmitted data andthe success or failure of 8b10b decoding; not just transmission andreception of IDLE bytes.

The physical layer 60 contains a status register 45 for eachtransmitting and receiving element of each node of the bus indicatingthe synchronisation status. For example, DISABLE (000001),UNSYNCHRONISED (000010), SYNCHRONISED (000100). Other state encodingsmay be used. Regarding the operation of the transmitter during initialsynchronization, IDLE bytes are sent in UNSYNCHRONIZED and SYNCHRONIZEDstates. Note that during initial synchronisation, only IDLE bytes aretransmitted to the bus. This is not the case in run-time operation whendata is transferred over the bus.

After the physical layer 60 has been configured into a run-time mode bythe application layer (parameter SET_RUN-TIME_MODE is set equal to 1),frame synchronisation can be performed. In run-time mode, messages (e.g.data, control or even empty) are transferred over the bus. In run-timemode, receiver synchronization of a transceiver is started immediately.When the value of parameter SET_RUN-TIME_MODE is changed from 1 to 0,state of the transceiver Is changed to FRAME_DISABLE.

In frame synchronisation, each transmitting element 40, 48 synchronisesthe frame timing with the baseband bus frame clock Furthermore, thestatus of the frame synchronisation in each receiving element 44, 52 isconstantly monitored. The end of each frame is identified from theunique IDLE byte K28.7. This unique IDLE byte allows one to calculatethe received frame offset as well as monitoring of frame synchronizationstatus.

In the present embodiment, frame synchronisation is applied to all thetransmitting and receiving elements of the bus nodes when entering therun time mode and the sequence of steps for frame synchronisation is thefollowing:

-   -   Set the state of the state machine to FRAME UNSYNCHRONIZED.    -   Reset the message group counter to zero.    -   Start transmitting empty or other valid messages from the        transmitting element 40, 48.    -   With reference to the baseband bus frame clock, read the IDLE        byte of each message group from the received byte stream using        the receiving element 44, 52. The IDLE byte must be the last        byte of the message group and any other IDLE bytes are        considered to be errors.    -   When the IDLE byte of a message group has been properly received        and no 8b10b decoding errors are present, consider that message        group to be valid. Otherwise, the received message group is        invalid.    -   When in the state FRAME UNSYNCHRONIZED and FRAME SYNC T        consecutive valid message groups have been received, set the        state to FRAME SYNCHRONISED.    -   When in the state FRAME SYNCHRONIZED and FRAME UNSYNC T        consecutive invalid Message Groups have been received, set the        state to FRAME UNSYNCHRONISED and reset the message group        counter to zero.

When in the state FRAME UNSYNCHRONIZED and FRAME DISABLE T messagegroups have been received, set the state to FRAME DISABLE.

The value of FRAME DISABLE T is always larger or equal to the value ofFRAME UNSYNC T. The status register 45 maintains an indication of thestatus of the frame where the status FRAME DISABLE, FRAMEUNSYNCHRONIZED, and FRAME_SYNCHRONIZED correspond to the states 001000,010000, and 100000 respectively. Other state encodings may also be used.When the transmitting or receiving elements enter the FRAME_DISABLEstate, the application layer is informed by an interrupt, which can thenrestart the synchronization procedure. Regarding the operation of thetransmitting elements during frame synchronization, valid messages aresent in the FRAME SYNCHRONIZED state, whereas empty messages are sent inthe FRAME UNSYNCHRONIZED and FRAME DISABLE states.

The synchronisation operation is now described for each respectivestate.

UNSYNCHRONISED

-   -   Restart the message group counter.    -   The transmitting element starts sending IDLE bytes.    -   The LOS is set to ‘1 ’.    -   The receiving element waits to receive data.    -   Valid bytes are beginning to be passed.    -   Initial byte synchronization is performed using the consecutive        K28.5 idle code    -   The receiving element will start counting valid message groups.        If SYNC T consecutive valid message groups are received, then        the state machine transitions to the SYNCHRONIZED state.    -   If DISABLE T message groups are received (with 400 bytes in        each), then the state machine transitions to the DISABLE state        and the Receiver and Transmitters are disabled.    -   If ENABLE BUS TRANSCEIVER=O is received, then the state machine        transitions to the DISABLE state.    -   If SET RUN TIME MODE=1, then the state machine transitions to        the FRAME UNSYNCHRONISED state.

SYNCHRONISED

-   -   Reset the message group counter.    -   Set the LOS to ‘0’    -   If UNSYNC_T consecutive invalid message groups are received,        then the state machine transitions to the UNSYNCHRONISED state.    -   If SET RUN TIME MODE=1, then the state machine transitions to        the FRAME UNSYNCHRONISED state.    -   If ENABLEBUS_TRANSCEIVER=O, then the state machine transitions        to the DISABLE state.

DISABLE

-   -   Stop all counters.    -   Set the LOS to    -   In this state, the state machine of the receiving element can        only transfer to the UNSYNCHRONISED state when RESTART FROM        DISABLE=1.

FRAME SYNC

-   -   Set the LOS to ‘0’.    -   Restart the message group counter.    -   Constantly check the frame synchronization using the K28.7 IDLE        byte.    -   If FRAME UNSYNC T consecutive invalid message groups are        received, then the state machine transitions to the FRAME        UNSYNCHRONISED state.    -   If ENABLE BUS TRANSCEIVER=0 or SET RUN TIMEMODE=0, then the        state machine transitions to the FRAME DISABLE state.    -   In the FRAME SYNC state, a valid message group exists when a        K28.5 or K28.7 IDLE byte code is at byte 399 and there are no        invalid IDLE codes in bytes 0 to 398 and no 8bl Ob decoding        errors are present.

FRAME UNSYNC

-   -   Set the LOS to ‘1’.    -   Restart the message group counter.    -   If FRAME_SYNC_T consecutive valid message groups are received,        then the state machine transitions to the FRAME SYNCHRONIZED        state.    -   If FRAME DISABLE T invalid message groups are received, then the        state machine transitions to the FRAME DISABLE state.    -   In the FRAME_UNSYNC state, a valid message group exists when a        K28.5 or K28.7 IDLE byte code is at byte 399 and there are no        invalid    -   IDLE codes in bytes 0 to 398 and no 8b106 decoding errors are        present.    -   If ENABLE_BUSTRANSCEIVER=O or SET RUN TIME MODE=O, then the        state machine transitions to the FRAME DISABLE state.

FRAME DISABLE

-   -   Stop all counters.    -   Set the LOS to ‘1’.

In summary, the idle bytes inserted into the frames at the physicallayer level are to synchronise the line rate of data transmission to thebus rate set up by the system clock. Also, synchronisation algorithmsusing these idle bytes to perform different types of synchronisationalgorithms. For initial synchronisation, before run time mode, thequality of the communication links between the nodes are tested bytransmitting message groups that consist purely of idle codes instead ofdata messages. The receiving elements then check the received idle codesand if all idle codes (i.e. 400 idle bytes in this embodiment) have beenreceived correctly, then that message group is said to be valid. IfSYNC_T consecutive valid message groups are received then initialsynchronisation has been achieved, For frame synchronisation, the firstalgorithm is when the bus is in run time mode but the frames areunsynchronised. Data messages and an idle message now make up themessage groups that are transmitted. However, now a message group isconsidered to be valid when an idle code exists (either K28.5 or K28.7)at the last byte of the message group (i.e. byte 399) and there are noinvalid IDLE codes in the remainder of the message group (i.e. bytes 0to 398) and no 8b10b decoding errors are present in the message group.Frame synchronisation is once FRAME_SYNC_T valid consecutive messagegroups have been received. Also, once frame synchronisation has beenachieved it is important to maintain synchronisation. This isaccomplished by using the unique idle byte (K28.7) at the end of eachframe, which allows one to calculate the received frame offset.

It should be appreciated that each transmitting or receiving element ofeach node of the bus can independently assume any of the statesdescribed herein.

It should also be appreciated that FIG. 3 shows a plurality of links,i.e. 1 to k. Thus, it should be understood that the present invention isscaleable to adapt to different data rates.

It should be appreciated that the frame structure shown in FIG. 5 is oneembodiment of the present invention. In this embodiment is that thespecial IDLE code 82 is inserted at the end of a frame 70. It should beappreciated that the baseband bus is a multi-mode bus and in conjunctionwith the layered protocol stack it is intended to support a variety ofdifferent air interfaces such as GSM or EDGE. With regards to the IDLEbytes 80, it should be appreciated that the position of the IDLE bytewithin the message group 74 may vary in different implementations.Furthermore, the special IDLE byte 82 might be implemented at otherlocations in each frame, for example at the start as opposed to the endof the frame 70: all that is needed is that it is in a predeterminedknown location. Also, the IDLE codes are 1 byte in length in thedescribed embodiment, however for a different embodiment these IDLEcodes could be scaled in length so as to match a different frame format.

It should be appreciated that the implementation of the nodes of thecommunications bus, shown in FIG. 3, are not necessarily limited toASIC's and can also be implemented using other logical devices, forexample a Field Programmable Gate Array (FPGA) devices.

1. A communication bus having nodes that are linked by communicationschannels, wherein a first set of said channels transfers information inone direction while a second set of channels transfers information inthe opposite direction, each of said nodes comprising: a transmittingelement for transmitting data to another node on said bus; a receivingelement for receiving information from another node on said bus; acommunication channel between said transmitting and receiving elementswithin each node; transmitter state machine logic for controlling thesynchronisation of said transmitting element; receiving state machinelogic for controlling the synchronisation of said receiving element; anda storage area for maintaining the status of synchronisation of saidbus.
 2. A communication bus according to claim 1, wherein thetransmitter and receiving state machine logic are configured to reportthe link status of the communication bus.
 3. A method of synchronisingdata communication over a communication bus, the communication bushaving nodes that are linked by communication channels, wherein a firstset of channels transfers information in one direction while a secondset of channels transfers information in the opposite direction themethod comprising: transmitting data from a first node on thecommunication bus over a communication channel; receiving data at asecond node in the communication bus; controlling synchronisingtransmitting the data with transmitter state machine logic; controllingsynchronising receiving the data with receiving state machine logic;maintaining the status of synchronisation of the communication bus;
 4. Amethod of synchronising data communication according to claim 3 whereinthe method further comprises reporting link status of the communicationbus.